home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / tls / tls018c.ltr < prev    next >
Text File  |  1994-09-02  |  7KB  |  155 lines
  1. Subj: TLS018c - monitor and trace utilities
  2.  
  3. Changes 13 May 93 to revision c:
  4.     remove gbcw
  5.                 - This version was too fragile; withdrawn.
  6.         - no longer being maintained.
  7.  
  8.     new version of trace:
  9.         - supports shared libraries
  10.         - intercepts sigprocmask and sigaction calls and
  11.           prevents them from blocking SIGTRAP
  12.         - SIGINT now terminates trace as claimed.
  13.         - if traced process forks, forked child no
  14.           longer dies with SIGTRAP
  15.  
  16. Changes revision "b"  17 Mar 93: new version of bcw handles larger number
  17. of buffer headers, displays buffer cache aging information]
  18.  
  19. ---------------
  20.  
  21. This TLS contains some interesting utilities and debug tools.
  22.  
  23.    memhog - displays utilization of cpu, memory, and i/o
  24.    bcw - buffer cache watch: display info about buffer cache
  25.    showreg - show regions attached to a process
  26.    trace - trace system calls
  27.  
  28. There are three directories:
  29. bin:
  30.     stripped binaries, compiled with static libraries
  31. man:
  32.     man pages for the commands in bin.
  33. cat:   
  34.         formatted man pages (nroff)
  35.  
  36. This is just a plain tar file.  You can decide where to install
  37. the bits and pieces.
  38.  
  39. Note that all programs except trace must be able to read /unix and
  40. /dev/kmem.  The safest way to set this up is to make /unix and /dev/kmem
  41. group mem, group readable, and make these programs sgid mem.  As
  42. shipped, they can only be run by root.
  43.  
  44. Also note that trace will not work on binaries stored on NFS filesystems
  45. unless you are running 3.2v4 (on the NFS client side).
  46.  
  47. Comments are welcome.  The author is Tom Kelly, tom@sco.com.
  48. See below for some useful comments from Jim Sullivan.
  49.  
  50. Dion L. Johnson
  51. SCO Product Manager - Development Systems  400 Encinal St. Santa Cruz, CA 95061
  52. dionj@sco.com   Compuserve: 71712,3301   FAX: 408-427-5417  Voice: 408-427-7565
  53. ===============================================================================
  54. Output from bcw:
  55.  
  56. buffers: 200 (200 K) hash slots:  64 pbufs:  20
  57. lread    0 bread    0 (hit 100) lwrite    0 bwrite    0 (hit 100) w:r   0
  58. in-cache 198 slots used  63 longest   8 shortest   1 async  0
  59. median chain:   3
  60. >120s:    0 >60s:    0 >30s:  159 >10s:   35 >5s:    0 >1s:    4 >0s:    0
  61. Busy   0 !Done   0 Want   0 Async   0 DelWri   9 Stale   0 Remote   0
  62. 132131 432321212142453334334733444231358545542244333155433523321
  63.  
  64. Explanations:
  65.  
  66. >>buffers: 200 (200 K) hash slots:  64 pbufs:  20
  67.  
  68. Buffers is the value of NBUFS, hash slots is NHBUFS and pbufs is NPBUFS
  69.  
  70. >>lread    x bread    y (hit 100) lwrite    z bwrite    v (hit 100) w:r   u
  71.  
  72. lread, bread, lwrite and bwrite are the same as is documented in the SAG
  73. for sar -b.  What this says is that during the last sample period, there
  74. were x logical reads (user programs read data that was present in the
  75. buffer cache, no disk access was required), y block reads (data was not
  76. found in the buffer cache, so we actually had to scheduled a read from the
  77. disk and wait for it to complete before we returned to the program),
  78. z logical writes (where the user programs have written data, but it is
  79. just being buffered in the cache) and v block writes (we've written v
  80. dirty buffers to the disk).  The ``hit'' number are the percentage of
  81. operations that went to cache instead of disk (lread/(lread+bread)) and
  82. lwrite/(lwrite+bwrite).  The w:r is the ratio of write to reads.
  83.  
  84. >>in-cache 198 slots used  63 longest   8 shortest   1 async  0
  85. >>median chain:   3
  86.  
  87. >>132131 432321212142453334334733444231358545542244333155433523321
  88.  
  89. Disk buffers are either in the cache or on the free list.  The in-cache
  90. number is approximately the number of buffers in the cache (approximate
  91. because it gets the number by adding up the lengths of the chains, but
  92. they could change during the summation period).  If you had 600 buffers
  93. allocated and the in-cache number is consistantly less than 600, you
  94. have too many buffers allocated and you can use that memory elsewhere.
  95.  
  96. slots-used is the number of hash buckets that actually have real buffers
  97. attached to them.  If you look at the final line (the row of numbers)
  98. you will notice that there is a single blank space.  In our example,
  99. there are 64 NHUFS (hash buckets) and one is not in use, at this time.
  100. slots-used is NHUFS-1=63!  If this number if significant less than NHBUFS,
  101. there may be a problem, since the disk buffers are not being distributed
  102. equally across the hash buckets.  We'll discuss this in a second.
  103.  
  104. longest and shortest represent the length of the longest and shortest
  105. hash chains.  The final line is the actual lengths of each hash chains.
  106. median chain is the median (the value in an ordered set of values below
  107. and above which there is an equal number of values, websters) of the
  108. hash chains.  Ideally, this number should be small (<=4).  Remember that
  109. when we do a read or a write, we first check the buffer cache to see if
  110. the data block is already in cache.  Each check consists of a comparison
  111. of the block addresses.  The algorithm looks something like this:
  112.  
  113.     calculate hash bucket (using block address)
  114.     ptr = start of hash chain
  115.     while( ptr.baddr != block address )
  116.         ptr = ptr.next
  117.  
  118. Ideally, you want to whip through this loop, because if the data block is
  119. not in the cache, you'll have to read it in.  If you spend too much time
  120. in this loop, then the buffer cache starts to get in the road.  This is
  121. why you should always increase NHBUFS to approximately NBUFS/4 when you
  122. increase NBUFS.  Our process to automatically determine NBUFS on startup
  123. is flawed in that it will not increase NHBUFS accordingly.  I suspect
  124. there are a large number of systems out there with NHBUFS=64 and NBUFS
  125. being dynamically determined at startup.  I've seen sites with NBUFS in
  126. excess of 2000, but NHBUFS still at 64.  Needless to say, disk performance
  127. is terrible.
  128.  
  129. If the last line has an asterisk in it, it means that the length of the
  130. hash chain is greater than 10, which obviously could be a bad thing.
  131. Many *'s means the buffer cache is not performing to its potential.
  132.  
  133.  
  134. >>>120s:    0 >60s:    0 >30s:  159 >10s:   35 >5s:    0 >1s:    4 >0s:    0
  135.  
  136. This is aging data.  Buffers get re-used depending on their age, with older
  137. buffers going first.  The idea is that if you are reading a particular
  138. buffer regularly, then re-using that buffer is bad.  You should re-use a
  139. buffer that is not used regularly.  The numbers presented here should
  140. add up to the in-cache number.  In my example, I have 159 buffers that
  141. have not been touched (read or written) in the last 30 seconds.  The idea
  142. came from the net, where there was a request to have this type of
  143. information.  With this info, you can get an idea of the total number of
  144. buffers you'd need, in general.  Remember that buffers do not get recycled
  145. until they are needed, so regularly used buffers (representing
  146. commonly read/written data) are never/rarely recycled.  If you have a
  147. large number of buffers in the 120 seconds field, then you MIGHT be able
  148. to reduce the total NBUFS number by that amount.
  149.  
  150. >>Busy   0 !Done   0 Want   0 Async   0 DelWri   9 Stale   0 Remote   0
  151.  
  152. This line represents that status of the buffers, and corresponds to the
  153. actual states that a buffer can be in. 
  154. ---------------
  155.